REMARKS 

This amendment is submitted in response to the final Office Action dated March 17, 
2003, wherein all of the pending claims (i.e., claim 1 - 13) of the application were rejected under 
35 U.S.C. § 103 as being "obvious" over a combination of supposedly admitted prior art and 
U.S. Pat. No. 5,953,010, to Kampe et al., and wherein FIGS. 5A, 5B, 6A and 6B were objected 
to. This amendment is being submitted with the accompanying Request for Continued 
Examination ("RCE") so that the finality of the March 17 Office Action is automatically 
withdrawn under 37 C.F.R. § 1.114, and entry of the amendment is appropriate. By this 
amendment, Applicant is submitting new informal FIGS. 5A, 5B, 6A and 6B, which comply 
with the Examiner's requirement that these figures be labeled "prior art". In addition, applicant 
has amended claims 1, 2, 6, 7, 9, and 1 1 - 13, to clarify what is being claimed and has added new 
claims 14 - 30. Accordingly, Claims 1 - 30 are pending in the application. Reexamination and 
reconsideration are respectfully requested. 

Applicant wishes to acknowledge the brief telephonic interview between the undersigned, 
the Examiner, and the Examiner's supervisor, Jeffrey A. Gaffin, held on June:13, 2003. 
Unfortunately, nothing was accomplished at this interview in view of Mr. Gaffin's position that 
no amendments to the claims would be considered. 

Claim Amendments and Additions 

Claims 1, 2, 7, 11 and 12, have been amended to specify that the "configuration 
messages" are internal messages. One purpose of this amendment is to further differentiate the 
present invention from the system disclosed in Kampe et al. which operates on text messages 
which are directed to the system display. While the term "messages" is used in Kampe et al, and 
in the present claims, they are very different concepts. Kampe et al. is concerned with otherwise 
unintelligible text messages which are difficult for the typical user to understand and which may 
only be displayed briefly. The present application utilizes the internal messaging used by a 
computer to alert various system components of actions. 

Independent Claims 1, 7, 1 1, 12 have been amended to specify that the notification to the 
user that it is unsafe to plug or unplug a peripheral device via the USB port occur within a 
fraction of a second. Claim 13 has been amended to specify that notice occur in "real time". 
One of the other of these terms in now incorporated into all of the claims, including the newly 
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added claims. Support for these amendments is found in the application as originally filed at 
page 3, lines 25 - 27; page 4, lines 7-8; page 5, line 7; page 12, lines 1 - 3; page 13, line 30 - 
page 14, line 3; page 14, lines 13-16; and claim 1. Specifically, the application as filed makes 
clear that the notification is for the intended purpose of alerting a human user via a "real time" 
screen display, of the status of the configuration of a plug and play device connected to the 
computer such as via a USB port. In human scale, "real time" notification generally corresponds 
to a fraction of a second. The application specifically refers to notice which "preferably" is 
displayed in a "small fraction of a second." Thus, the term "fraction of a second" is supported, is 
appropriate and is sufficiently specific. 

Claim 1 and 7 have been amended to eliminate the specific requirement that the operating 
system have "first" and "second" "subroutines" for generating internal configuration messages. 
It is believed possible that a single subroutine could be used to generate both types of 
configuration messages, and the precise operating system architecture for generating internal 
configuration messages is not considered to be part of the Applicants' invention. 

Claim 6 has been amended so that it no longer requires the use of a "speaker". As 
indicated in FIG. 5 A, the audio output could be directed to a headphone jack (590 on FIG. 5 A) 
rather than to speakers. In any case, the audio signal is directed to an audio output port, and it is 
the user's preference whether the audio signal will be delivered via speakers or via earphones. 
The use of a speaker is now incorporated into new claim 24. 

Claim 7 has been amended to improve clarity concerning the relationship of the various 
USB and non-USB ports, and to eliminate unnecessary preamble language which might have 
been construed as limiting. 

Claim 9 has been amended to eliminate potentially limiting language which does not add 
to the patentability of the claim. 

Claim 12 has been amended to add clarity and to eliminate potentially limiting and/or 
redundant language which does not add to the patentability of the claim. The term "USB 
devices" was incorrectly used, as the present invention also relates to non-USB devices which 
are coupled to the computer via a USB hub having non-USB ports thereon. 

Claim 13 has been amended to provide a more accurate preamble and to limit the claim to 
USB configuration notification. 

New claims 14 - 18, 21 - 23, 25 and 30 all require that notification be given in the 
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"system tray 9 of the operating system. Support for this is found on page 14, line 27 - 28, of the 
application as filed. 

New claims 17, 22 and 26 all require the use of color-coded notification. Support for this 
is also found on page 14, line 27 - 28, of the application as filed. 

New independent claim 28 is directed to the notification program alone, to provide 
coverage when such a program is sold or provided separately from the other computer 
components. 

Response to Rejections 

Claim 1 was rejected under § 103 as being obvious over "admitted prior art" in 
combination with Kampe et al. Applicant respectfully traverses this rejection. There is no 
admission by the applicant that a "configuration notification program" for handling internal 
system messages, as set forth in claim 1, is known in the prior art. In addition, the application 
specifies that to the very limited extent it was known in the prior art to provide any notification 
that a device connected via a USB port is undergoing configuration, the only admitted 
notification is an ambiguous "system busy" hourglass symbol which may appear on the display 
screen in place of the mouse cursor. The application points out that this "system busy" 
notification (1) does not constitute a warning to the user that the USB port is being configured 
and (2) does not respond in real time. As any user of the Windows operating system appreciates, 
the hourglass symbol appears many time for many reasons, and its appearance is thus 
ambiguous. Moreover, the appearance merely gives notice that the system is busy and may not 
be immediately responsive to further inputs. The hourglass does not warn the user that taking 
certain actions when the hourglass is displayed may cause the system to crash. 1 Moreover, the 
hourglass symbol is not updated in real time, i.e., within a fraction of a second of when an event 
occurs. It is the multiple deficiencies with the "system busy" icon which, in part, led to the 
present invention. 

Kampe et al. discloses a program which intercepts text messages directed to the system 

l For example, this document is being prepared using a word processing program 
operating under the Windows operating system. Multiple times during the course of document 
preparation the "hourglass" icon has appeared, indicating a system busy state associated with 
automatic saving of timed back-up copies of the document. This icon does not require that work 
be stopped, as continued typing is cached and displayed after the hourglass disappears. 
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display during the system initialization or "boot-up" process, and substitutes icons or other 
indicators concerning the status of the initialization process which are more informative and user 
friendly. Kampe et al. also discloses a logging system for recording the initialization process so 
that any boot-up errors can be identified after-the-fact by reviewing the event log. Thus, while 
the reference teaches a mechanism for determining the cause of a system crash during the 
initialization process, it has nothing to do with providing real time information which is useful 
for the purpose of preventing problems from occurring. 

Moreover, Kampe et al.'s program does not operate on internal messages relating to 
device configuration, nor is there any suggestion that the program be modified to act on such 
messages. (In a briefly described second embodiment, Kampe et al describes the concept that 
their iconic messages could be generated by the operating system directly during the boot-up 
process. However, this embodiment is also unconcerned with message or device monitoring.) 

Kampe et al. is not concerned with providing real time notice to avoid system crashes 
associated with plugging and unplugging peripheral devices. Rather the Kampe et al. program is 
merely for the purpose of logging and displaying in a user friendly manner system boot up 
information. Because Kampe et al is limited to this purpose, there is no need to provide the user 
the type of real time information which is required to avoid system crashes. Thus, Kampe et al. 
specifically teach that their information need only be updated "every few seconds", and that the 
update intervals of "20 to 40 seconds" are within the scope of their invention. These time frames 
may be adequate for a program which is merely intended to monitor the progress of system 
initialization, but are inadequate to provide the real time notice required to avoid system crashes. 

(The March 17 Office Action suggests that the examiner appears to believe that the 
language "every few seconds," as used in Kampe et al., applies only to "progress updates" as 
opposed to "milestone events". It is submitted that this is incorrect. The "Summary of the 
Invention" states: 

"The present invention overcomes the drawbacks and limitations of the 
prior art by converting a system program which originally produced a text-based 
startup message display into a graphical startup message display which generates 
and displays user- friendly iconic messages representing milestone events that are 
readily intelligible to a typical computer user. The icons are updated every few 
seconds and accurately indicate the progress of loading and running the system 
program as well as indicating any failures and corresponding actions that should 
be taken." 
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This language clearly confirms that both "milestone" and "progress" icons are updated only 
every few seconds, and nothing in the reference suggests any reason to do otherwise.) 

Kampe et al. is completely unconcerned with the status of "plug and play devices" 
containing no mention of them, or of USB (or other) ports, or of the problem of system 
instability when devices are being configured. 

It is submitted that there is no motivation shown for combining the "system busy" 
hourglass icon of the admitted prior art, with the Kampe et al program for intercepting difficult- 
to-comprehend text messages directed to the computer screen to provide enhanced monitoring of 
system initialization. 

The lack of appropriate motivation to combined these references is further shown by the 
fact that neither the "admitted prior art" nor Kampe et al. recognize the system instability 
problem associated with connecting devices to a computer via a USB port, especially via a USB 
port which is a compound hub having non-USB device ports. The known prior art does not 
suggest any awareness of the problem or of the associated increases risk of system crashes. It is 
believed that the prior art assumed that USB ports and devices are stable and no special 
precautions were required to control the process of connecting and disconnecting devices via a 
USB port. Thus, part of the invention lies in the recognition of the problem, and in the means for 
solving the problem. It is submitted that the Examiner is using hindsight gained from the present 
application's teachings concerning the problem to be solved, to pick and choose features from 
the prior art to allege the obviousness of the present invention. 

The fact that the discussion of the problem being solved by the present invention is found 
in the "Background of the Invention" cannot be construed as an admission that the problem was 
known in the prior art. It is the Examiner's burden, in establishing obviousness, to show the 
existence of a suggestion or suitable motivation to arrive at the present invention. 

Thus, in summary, the rejection of claim 1 cannot stand because, inter alia, the 
combination of the "admitted" prior art and Kampe et al., does not make obvious a program to 
intercept internal system configuration messages and to use this information to provide real time 
notification to the user that is it unsafe to couple or uncouple a "plug and play" device. 

With regard to claim 2, the Examiner fails to show any motivation to modify the so- 
called admitted prior art to arrive at the present invention. The admitted prior art relates to 
circulating internal binary messages to various programs running on a system such that inputs 
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which may be relevant to a particular program are delivered to the program. Thus, for example, 
entry of a particular keystroke combination might be cause a machine code message to be 
circulated by the operating system and delivered to all running programs, causing any programs 
which have an output being displayed on the system monitor to "minimize" their display. 
Kampe et al. relates to intercepting text messages being sent to the display. These are very 
different types of messages, and the Examiner has failed to explain why someone of ordinary 
skill in the art would want to modify a system which intercepts text messages during system 
initialization to monitor internal messages which relate to plug and play device configuration. 

As to claims 3 and 8, neither reference shows or suggests using three different indicators 
to indicate the status of a plug and play device port. The Examiner fails to show where this 
appears in Kampe et al. Kampe et al. has no teaching concerning the status of device ports, nor 
does it teach the use of three distinct indicators. 

As to claims 4 and 5, the Examiner's rejection is not clear. Applicant admits that USB 
ports and hubs are known in the prior art. However, there is nothing in Kampe et al. which 
relates to USB ports or serial ports, and so it is not clear why one would look to Kampe et al. for 
teachings concerning monitoring such ports. As disclosed in the application, it is believed that 
the use of a compound USB hub enhances the problem of system crashes associated with 
untimely connection of plug and play devices. This problem is not disclosed in the known prior 
art, and so there would be no motivation to employ a real time monitoring system. 

As to claim 6, the Examiner is required to show a reference which teaches the claimed 
combination. It is insufficient to merely allege that an important element of a claim was "well 
known." And, even if it could be shown that the element itself was known, the Examiner must 
further show a suggestion or motivation for the claimed combination. Specifically, it is 
insufficient for the Examiner to use hindsight to pick and choose elements from a variety of 
disparate references. 

Claim 7, 1 1 and 12 are distinguishable over the prior art for the same reasons as claim 1 . 
Specifically, they require, inter alia, that notification occur in real time (i.e., within a fraction of 
a second), and that the system operate on internal messages generated by the operating system 
when a plug and play device is coupled to the computer via a USB port. Again, Kampe et al. 
does not teach real time notification, does not teach device peripheral handling, does not teach 
anything concerning USB ports or plug and play devices, and does not teach anything 
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concerning the processing of internal configuration messages. There is no reason why the 
teachings of Kampe et al. would be combined with any admitted prior art. 

As to claims 9 and 10, the present application teaches that the problem of system crashes 
appears to be more pronounced when coupling non-USB plug and play devices via a USB 
compound hub. This teaching, which provides a part of the motivation for the present invention, 
is absent from the known prior art. 

As to claim 13, the prior art does not teach real time notification of when it is unsafe to 
plug or unplug a USB device. 

New claims 14, 17, 18, 21 - 23, 25 and 30 all require that the safety notification be send 
to the "system tray" of the operating system. There is no teaching or suggestion of this in the 
prior art of record. 

New claims 17, 22 and 26 all require that the notification be color coded. This feature, 
which enhances user friendliness, is not shown or suggested in any of the prior art of record. 

New claim 14 requires the use of text information in the system tray icon. This feature is 
not shown or suggested in any of the prior art of record. 

New claims 15, 16 and 29 all require the use of "unique indicators" for the status of the 
USB port. This is to differentiate from the generic "system busy" indicator used in the admitted 
prior art. 



For the foregoing reasons, it is submitted that claims 1 - 30 are in condition for 
allowance and such action is earnestly solicited. The Examiner is invited to call the undersigned 
at the phone number listed if doing so might advance prosecution of the application. 



Sheppard Mullin Richter & Hampton LLP 
Four Embarcadero Center, Suite 1700 
San Francisco, CA 941 1 1 
415-434-9100 
415-434-3947 (fax) 



Conclusion 




David Schnapf / 
Registration No. 3lp66 
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